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REMARKS 

In response to the Office Action mailed July 9, 2004, claims 1 - 7 have been cancelled, 
and claims 8-20 are newly added. Claims 8-20 are now active in this application, of which 
claims 8, 1 5 and 20 are independent. 

Based on the attached Amendments, Substitute Specification, Replacement Drawings and 
the following Remarks, Applicants respectfully request that the Examiner reconsider the 
outstanding objections and rejections and they be withdrawn. 
Rejections Under 35 U.S.C. §102 

In the Office Action, claims 1 - 7 have been rejected under 35 U.S.C. § 102(e) for being 
anticipated by U. S. Patent No. 6,735,593 issued to Williams. This rejection is respectfully 
traversed. 

For anticipation of a claim under 35 U.S.C. § 102, a single prior art reference must 
contain each and every limitation of the claim. In re Bond, 15 USPQ2d 1566 (Fed. Cir. 1990); 
Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1570 (Fed. Circ), cert, denied, 488 
U.S. 892 (1988). As Williams does not teach each and every limitation of any amended claim, 
Williams does not anticipate amended claims 8 -20. 

Specifically, Williams describes a relational associative model, which has no relation to a 
network model database schema as claimed. Williams requires relational tables, whereas the 
claims are directed to a network database which does not use relational tables. Additionally, 
Williams provides no schema, much less a schema as taught in the subject Application. In lieu 
of a schema, Williams provides a relational model and relational tables using SQL operators, 
instead of procedural routines. Furthermore, Williams teaches neither primary branches nor a 
relationship branch. Williams also does not teach a record type that includes a context code and 



8 



Sroka 
09/639,961 

a phrase value. Consequently, Williams cannot handle multiple meanings of the same word 
because there is no Context. Williams also cannot handle multiple languages. Moreover, 
Williams does not teach a set that defines relationships from a record type to another record type. 

The terminology of elements of Applicant's exemplary schema (e.g., noun, verb, item 
and note) are selected for illustrative purposes, but do not limit the invention. Despite the 
possibility of shared terminology, the elements of Applicant's schema are in no way related to 
Williams. Illustratively, as used by Williams, a verb is not a record type that includes a 
hierarchy and a network to connect entities. 

As Williams requires relational tables, redundancy is a problem. Using Williams' 
relational design every relation link must be repeated as a row in a table - thus causing 
redundancy. If Williams encounters 20 sentences with a word "I", then Williams will have 20 
rows in a relationship table connecting "I" to 20 different sentences. In sharp contrast, 
Applicant's network model design uses "I" and pointer connections. 

Accordingly, Applicants respectfully request that the rejection over the claims be 
withdrawn. 
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CONCLUSION 



All of the stated grounds of objection and rejection have been properly traversed, 
accommodated, or rendered moot. Applicant therefore respectfully requests that the Examiner 
reconsider all presently outstanding objections and rejections and that they be withdrawn. 
Applicant believes that a full and complete response has been made to the outstanding Office 
Action and, as such, claims 8-20 are in condition for allowance. If the Examiner believes, for 
any reason, that personal communication will expedite prosecution of this application, the 
Examiner is invited to telephone the undersigned at the number provided. 

Prompt and favorable consideration of this Amendment is respectfully requested. 



Date: October 5, 2004 

Mark Young P.A. 

9951 Atlantic Blvd., Suite 227 

Jacksonville, Florida 32225 

Tel. 904-721-0600 

Cell. 904-571-8141 

Fax. 904-721-0686 

myoung@myoungpa.com 

Attachments: Substitute Specification 
Replacement Drawings 

Change of Correspondence Address and Power of Attorney 



Respectfully submitted, 




Marl^ToWng 
Reg. No. 39,436 
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U.S. Patent Application of Al e xander Sroka 
for 

S e lf Organizing and Automatically Cros s Referencing Information Management 

Sy s tem 



SELF-ORGANIZING AND AUTOMATICALLY 
CROSS-REFERENCING INFORMATION MANAGEMENT SYSTEM 



Background — Field of Invention 

Field of the Invention 

This invention relates to computer programs, specifically to arcomputer 
information management systems which organize and access information stored in computer 
systems. 

Background 

Computer systems sometimes organize data into categories and items related to 
such categories. Categories may be organized in hierarchies or structures. For example, 
category "Companies" may contain a list of specific company names, like "Financial 
Services, Inc.", "Environment Care Corp." and "Computer Maintenance, Inc.". Items are 
specific textual strings containing a single word, two, three or up to acouple of hundred 
words A text, or other information pieces. 

Prior art systems does not efficiently h andle e fficiently apractically unlimited 
number of categories and items and/or cannot de-cross-referenceing fe^such ajarge number 
of categories and items. 

Background — D es cription of Prior Art 

Currently, the prevailing implementations for Information Management Systems 
handling diversified pieces of information on the-personal computers are utiliz e d in Personal 
Information Managers (PIM). No single product on the market fulfills the requirements of 
easy interface, database strength, extendibility, flexibility or other specific features, tike -such 
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as handling p ractically an unlimited number of categories and items or, most more 
importantly, automatic ally storingage-ef cross-referencing between categories and items. 

There are/were the following major competitors in existing PIM's market for personal 
computers: 

• Maximizer ®~ with a_strong Btrieve database, but no cross-referencing?; 

• Lotus Organizer® - with a strong visual interface, but no database — and no cross- 
referencing?; 

• Act! ® ~ with a d atabase - and contact manager, but no cross-referencing?; 

• Lotus Agenda® ~ with (DOS-based) cross-referencing, unusabl e — DOS bas e d, no 
database, now deftmetobsojet^; 

• ECCO® ~ with, arguably, t he best interface, but no database?; 

• Lotus Notes® — not a PIM, but provides intelligent e-mail and document storing. 
On the low end o fO ther information managing and scheduling programs are: 

• InfoCentral® — which provides information outlining, 

• Schedule+® ~ which provides n etworked scheduling, 

• Network Scheduler® 3 — which provides networked scheduling. 

Lotus Agenda®, when it was commercially available, is -was p rotected by the U.S. Pat. 
No. 5,1 15,504 issued to Belove et al. This -The Belove p atent is-4e rdiscloses a methodology 
which tries t o accomplish a similar task as the present invention.? However, the Belove 
methodology b y -uses a different system implemented in a DOS based database. The design of 
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the Belove system was cumbersome, limited to a linking file system and did not utilizing 
utilize t he-a modern network data model design. It was creating mor e probl e ms th e n it was 
solving . 

Act!® is recommended only for sale force automation^ Maximizer® is recommended 
for a broad spectrum of tasks iT and -Lotus Organizer® is preferred by some users. An E ase 
easy to useo f interface is the single most important factor for the mass-market users. Theft 
com e th e database and networking capabilities are les important . 

The invention is directed to overcoming one or more of the problems as set forth 

above. 

Summary Including Obj e ct s and Advantag es 

Summary of the Invention 

To solve one or more of the problems set forth above. T his inv e ntion is a sp e cific a 
software and/or hardware Ddatabase- (Database) with a design and algorithms to access 
information in this-the Database is provided . The Database is a model of the-reality. The most 
prevalent characteristic of the Database is its-thatjLself-organizesing e£information contained 
in the Database. The Database content is dynamic and effectively changing changes t he 
Database itself. 

Humans always use words and phrases to describe the-reality. The-sSentences are baiid 
built primarily with nouns and verbs. The meaning of what is said depends on the context in 
which words are used, then it is conc e ntrat e d concentrates on a particular view of the things! 
and finally the things have their names. 

ADatabase according to the invention uses nouns, verbs, context, views and names 
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these words t o classify the-information. ft -The methodologies employed by the Database is 
intuitive^-fe«t4If somebody prefers to use a different naming convention, the Database can be 
adjusted by customizing it. The Database includ e s utilizes automatic cross-referencing 
algorithms methodologies t o relate categories and items of information. .Main design views of 

the Database are presented here for illustrative purposes. eOthe re design views- which are 

not presented here , including variations of the main design^ are intended to come within the 
scope of the covered also by this invention. The look and feel of the-computer programs which 
d e al with provide a user friendly spreadsheet presentation of the Database information and 
particularly Name and Context combo A are described below . A«y computer system wkh 
having means ef-for implementing the invention is also described. 

Object s and Advantag e s 

Th e obi e ct Obiects of the invention is-are to reduce redundancy of data storage, 
improve the performance of retrieving data and automate the process of categorizing 
information the -in a way similar to human brain categorization. 

Accordingly, several objects and advantages of the invention ar einclude the 
provision of an information management system that provides : 

4-r-A network database design, which easily categorizes and stores any number of 
pieces of information^ 

2r-A database basic op e ration algorithms svstem that is c losely related to the 
database structure . Th e specific , with adatabase design that p uts organization organizes and 
structures-te the way the-specific pieces of information can be stored and browsedr; 

^-A database system with automatic cross-referencing automatic algorithms that 
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are based on the database design-whie k and stores ^^relationships between categories and 
items, categories and categories, as well as items and items;7 

4r-A database system with self-organizing and self-learning algorithms that store 
statistical access or other information used to reorganize access paths to specific categories, 
items and their relationships-r^fri s, which such information may be changedr-; 

5. Th e look and f ee l of th e us e r int e rfac e to th e databas e . Th e A jtser interface that 
uses -provides a spreadsheet parall e l look and feel t o display in rows ahierarchy of categories 
and items related to these categories, . In spreadsh ee t column s ar e displayed and to display, in 
columns, categories which may be related to the items through other categories, which 
generally are -may be sub-categories of the-column categories. 

&-AName and Context Combo combo in the-auser interface to the dDatabase? 
Tto accommodate display of different categories (Names^ which may have the same Name? 
but ardifferent meanings depending on the context in which t hey are used, the display includes 
means of viewing and manipulating Name/Context combinations. 

2r-A computer software program e mbodying a comprised of computer code for a 
Personal Information Manager, said program comprising o fi ncluding subroutines for entering, 
viewing and editing of user^s data with the spreadsheet interface, for retrieving ef-user^s data 
with automatic cross-referencing of data 4 and for enabling the system^ to perform self- 
learning based on statistical access information. 

Still further objects and advantages will become apparent from a-consideration of 
the ensuing description and accompanying drawings. 
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Brief Description of the Drawings 

Figure 1 shows a category structure according to principles of the invention; 

Figure 2 shows a standard category structure for the View Context according to 
principles of the invention; 

Figure 3 shows a structure of a database information model according to principles of 
the invention; 

Figure 4 shows a simplified structure of a database information model according to 
principles of the invention; 

Figure 5 shows a structure of a sample category classification according to principles of 
the invention; 

Figure 6 shows elements of a simplified database information model according to 
principles of the invention; 

Figure 7 shows Elements of a Database according to principles of the invention; 

Figure 8 shows a realistic schema of a database for reality, with a dictionary that reuses 
reality elements according to principles of the invention; 

Figure 9 shows a quantified elementary information according to principles of the 
invention; 

Figure 10 shows elements of the quantified elementary information according to 
principles of the invention; 

Figure 1 1 shows an illustration for the basic retrieval algorithm according to principles 
of the invention; 
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Figure 12 shows dimensional query results of the basic retrieval algorithm according to 
principles of the invention; 

Figure 13 shows a basic structure of a Noun (Verb) record according to principles of the 
invention; 

Figure 14 shows a basic structure of a Relationship (or Structure) record containing 
usage count or certainty factor according to principles of the invention; 

Figure 15 shows a product of Nouns (Verbs) and a structure of Nouns (Verbs) with 
three elements according to principles of the invention; 

Figure 16 shows an example of product of Nouns (Verbs) and a structure of Nouns 
(Verbs) with four elements according to principles of the invention; 

Figures 17A-17L show the RAIMA? database data definition language schema for 
BrainAgenda™ according to principles of the invention; and 

Figure 18 shows two dimensional query results of a basic retrieval algorithm and 
elements of the spreadsheet interface, with a Name and Context Combo displayed according 
to principles of the invention. 

Detailed Description 

Concept s of Database 

All drawings The Figures and the p referred embodiment of a Data Definition 
Language as described below use standard notation developed by the CODASYL Database 
Committee. JFhe^Rectangular boxes in the Figures represent R e cord record T ype stypes, 
arrows represent Relationships relationships between R e cords records . Each arrow represents_a 
one to manv one-to-many relationship. 
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th e main parts of th e databas e Provided below are descriptions aferof 
• _acategory structure^ 

• categorizing of information, 

• _elements of a_simplified database^ 

• elements of a_database a 

• a sample sample of th e b e tt e r d e v e lop e d a database^ 

• a theory -theory behind the-adatabase A 

• basic cross-referencing algorithms of the-a_database a and 

• self learning algorithms of the-a database for an information 

management system according to principles of the invention. 

Category Structure 

A database user builds his/her business by knowing understanding his/her 
products and the procedures to deliver them. A Databas e database according to principles of 
the invention produces the Items of information (the product); by learning from the user how 
the user wants to find the Items (the procedure). The-eCommonly used descriptors tike -such as 
date and tin^ or the-other preloaded Databas e database categories do not fteed -require any 
explanation. Bufc -However other categories , for example, a manager's name or names of 
companies with which a business deals, may be at-used only by -within a specific user's 
business , for exampl e , manag e r's nam e or th e names of compani e s a busin e ss is d e aling with . 

The Databas e d atabase l ets -allows a user to p ut -introduce his/her knowledge into a 
structure, which is as depicted in Figure 1 . .In a specific Context l x auser can define many 
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Names 3. The Relationship 2 between aContext and Name is one-tcwnany optional on both 
sides of the Relationship 2. For example, in Context Work a user can create Names of co- 
workers, Alex, Barbara, Jan and Agnes. 

Each Name in the Database has a specific Context assigned to it at the time of 
creation of the Name in the Database. A View 4 is a collection 5 of Names 6 (and their 
Contexts) as defined by the user at the time of the specific Name 6 entry. Context may also be 
used as a View. 

Usually Typically, t he-View or Context 4 (or 7) is used to have -provide a 
collection of Names 6 (or 9) in a required setup 5 (or 8). : Fheft r Figure 2 conceptually 
illustrates the category structure within the-a_View or Context th e cat e gory structur e is lik e on 
Figur e 2 . Each Name in View can be used in a different Context. For example, a View 
Activity can contain Names: Calls, Meetings, Mail and Follow upUp; a View People can 
contain Names: Peter, Jack, Barbara, Tiffany, Mark and Ken. 

It is recommended, that a user starts working with the structure as shown on the 
Figure 2, without using Names from contexts other than Global. When a_user sees -perceives 
the-a_need for differentiating the meanings of a particular word in different contexts, then 
he/she can start to use different contexts. 

For example, there is alr e ady cr e at e d a View People with Nam e may contain 
names of the people from the business s : Peter, Jack, Barbara, Tiffany, Mark and Ken, 
containing names of th e p e opl e from th e busin e ss . Then-Auser may entered an Item with the 
text "Call Barbara at 2:30 PM n , meaning to call the user's wife, whieh -whose ha s th e first 
name is_Barbara, which is the same as ene -the first name of a buser's coworke r of the users . 
The system has assign e d assigns t he Item "Call Barbara at 2:30" to Barbara from the business, 
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because it didn ^oesn't know about user's wife. Now, what us e r is supposed to do, is to t o the 
user may add Barbara from View People, to a new Context Home. In effect, Barbara will be 
related to two Contexts, namely Work and Home. 

Categorizing Information 

A tJse ^user enters th e pi e c e s information to the system through Items 1 1 (109). 
Items are entered on the View Form (screen) A as in Figure 18. A_Uuser may enters the Items 
1 1 (109) for a Name 9 (106, 108). Each Item may be assigned 10 to many Names (106, 1 12). 
The full structure of the Databas e database system is shown on Figure 3. 

A tfeer -user can create as many as he/sh e wish e s Contexts - and Views as he/she 
wishes. Many Names?- can be assigned t o each View, can b e assign e d many Nam e s Likewise, 
and -many Items can be assigned t o each Name can b e assign e d many It e m s . Each It e m may 
be assigned to many Names. There is no limit on how many of these elements can be created. 

Contexts, Views and Names together create Categories 12. All Categories 12, all 
Items 14 and all many -many-t o-to-many connections 13 between Categories and Items in the 
Database are stored in aDatabase called Neuron. The simplified structure of the Database is 
depicted as shown in Figure 4. 

Th e pres e nted in Referring now to Figures 3 and in Figur e 4 the structure of the 
Database , which is totally flexible and extendible, is shown, becaus e th e r e can b e cr e at e d 
many -Many levels of classification can be created . For example, a us e r can hav e th e structure 
e£categories and an Item - can be structured as shown en-in Figure 5 . In this Figur e 5 , where 
arrows 16, 18, 20, 22, 23, 27, 28 and 29 depict the-physical pointers between specific 
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categories/items. These pointers are merely one ef-possible physical implementation of 
relationships. 

In this-the example of Figure 5, user has there are five categories: Activity 15, 
Follow Up 17, Leads 19, NOVACORP 21, Smith 22' and an Item "Call Smith tomorrow and 
meet him Monday" 30. Each of the categories can become a View and/or a Name. At the time 
of the-entry A the Item "Call Smith tomorrow and meet him Monday" is automatically assigned 
to other categories: Calls 24, Tomorrow 26, Meetings 25; and other standard (not shown here) 
date categories: Tomorrow's Date, Monday (next) and next Monday's Date. All categories can 
have their own structures or can participate in any structures. Together, all category structures 
in the Database reflect a_user's own information network. 

Elements of Simplified Database 

In th e pr e viou s s e ction Categories 31 and Items 36 were -are described above . 
They are the most frequently used elements of Database. The-Notes 33 are the next element of 
Database. Notes are not utilized in the-automatic assignments, like Items and Categories, but 
are usefet -used to store-the additional information attached to any Category or Item, As 
th eWhile Items are limited in size, to make their processing efficient, the-Notes are actually 
unlimited in size. One note can have many pages, and one page contains around 
approximately one printed page of text in the preferred embodiment. The number of notes is 
can be p ractically unlimited. Notes are attached 32, 35 to Categories and Items, but there can 
also be also notes N otes by themselves alone, not connected to any other element of the 
Database. However, it is recommended that Notes are attached to at least one Category or 
Item, b e cause this wav so that - they can be easily found out. Otherwise, a user may h as -have t o 
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remember a nete^s -Note's identifier, or weald-may have to scan all notes, to find the right one. 
Figure 6 shows how the Notes relate to other elements of Database. 

The Simplified Database is made up of Items, Categories and Notes. All of these 
database elements can be related to each other 32, 34, 35 in many to manv many-to-many 
relationships. 

Elements of gJDatabase 

The basic configuration of the Database allows to-stef estorage of any information. 
Categories are divided into Nouns and Verbs. A part of the Database is called the Noun 37 
branch, because all parts in this part are nouns. A Similar similar structure is created for the 
verbs. This part of the Database is called the Verb 38 branch. The full Database contains both 
branches being connected by Item 41. Use of one or both branches constitutes use of the 
Database. Figure 7 shows how all three elements (i.e.. Nouns, Verbs and Items) relate to each 
other in the Database. Additional long pieces of text are stored in Notes 42. The many to 
fflan ymany-to-many relationships 37", 39, 40, 37' and 38' relate Elem e nt s elements o f the 
Database to each other. 

Sample of tke-abetter developed D atabase 

In any databas e information management system developed on the four element 
Database as shown in Figure 7, the branches gefc -become more complicated to stor e int e rnal to 
the- as branches relationships and additionally relationships between -the branches are stored . 

Full implementation of the invention should preferably c reate two databases: 

- one without Items — called a_Dictionary and 

- one with Items - called Reality. 
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Figure 8 shows on e of a possible implementations of the Database developed with 
Items. The database has the-a_Start 43 record, which is used as the owner of the sets 44 and 62 
for sequential retrieval of Main Noun 45 and Main Verb 63 records. 

The Noun Branch is d e v e loped to classify classifies and stores the-hierarchical and 
network relationships between the-elements of the Noun Branch. Main Noun record 45 is th e 
own e r o f owns a collection 45' of Noun Group Records 46. Noun Group 46 is th e own e r of 
aowns collection 45" of Noun Records 49. Structure Record 47 is th e record to stores the 
many to manv manv-to-manv relationships 50 between Noun Group Records 46. These 
relationships 50 are implemented as a double set from Noun Group Records 46 to Structure 
Record 47. Structure Record 48 is th e record to stores th e many to manv manv-to-manv 
relationships 51 between Noun Records 49. These relationships 51 are implemented as a 
double set from Noun Records 49 to Structure Record 48. Item Record 55 is related many to 
man ymany-to-many to the Noun Record 49 via Noun-Item Relationship Record 53 and 
relations 54 and 54'. 

The-AV erb Branch is d e v e loped to classify classifies and stores the-hierarchical 
and network relationships between the-elements of the Verb Branch. Main Verb record 63 is 
th e owner o f owns a collection 63' of Verb Group Records 64. Verb Group 64 is th e own e r of 
owns a collection 63" of Verb Records 65. Structure Record 66 is th e record to stores-the 
many to many many-to-many relationships 68 between Verb Group Records 64. These 
relationships 68 are implemented as a double set from Verb Group Records 64 to Structure 
Record 66. Structure Record 67 is th e record to stores th e many to manv manv-to-manv 
relationships 69 between Verb Records 65. These relationships 69 are implemented as a 
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double set from Verb Records 65 to Structure Record 67. Item Record 55 is related many to 
fflafwmanv-to-manv to the Verb Record 65 via Verb-Item Relationship Record 72 and 
relations 73 and 73'. 

Structure Record 75 is th e r e cord to stores th e many to manv manv-to-manv 
relationships 74 between Item Records 55. These relationships 74 are implemented as a 
double set from Item Records 55 to Structure Record 75. 

Noun Record 49 is related many to manv manv-to-manv to the Verb Record 65 via 
Noun-Verb Relationship Record 71 and relations 52 and 70. 

Item 55 is further analyzed into Item Analysis Records. This -The schema has Item 
Analysis Records 57, 58, 59 and 60. Item Analysis Records are related to Item Record 55 via 
relation(s) 56. These relations may be implemented as a single set or multiple sets. 

Note Record 61 in this-the schema is not related directly to Noun 49, Verb 65 or 
Item 55. There are direct relations, but for efficiency reasons they are implemented as direct 
Noun 49, Verb 65 or Item 55 key duplication in Note Record 61. 

Theory behind the Database 

The Database follows theoretically the analysis of sentences in any language. Full 
sentences in any language contains Nouns, Verbs and quantified information about the noun 
operated by the verb. Such quantified information can be fully analyzed. Some sentences are 
not fully quantified, but logically they still follow the full model. (Parts are less than the 
whole). 

By definition, elementary information is a simple sentence describing a_state of an 
observed event or process. 
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Quantified elementary information, by definition, is a sentence with an argument 
describing ajesult of measuring of an object state. In the most complicated form^a-quantified 
elementary information contains results with discrete measurement results. 



Name 



Number 



<= 



>= 



> 



(any of) 



Where: 



Name -- name for the Number 



Number - Real Number 



= <= >=, <, > — functors creating sentences, semantics like in theory of real numbers 



Quantified elementary information is separated into three parts: 

- Noun, 

- Verb, 

- Item. 



Noun and Verb are analysis o f based on the Name, and Item contains the Number. 
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Using network data model notation (CODASYL) the model in Figure 9 directly 
translates quantified elementary information into a database language. Noun 76 is in many to 
man ya manv-to-manv relationship 77 te -with Verb 78. Verb 78 is in many to manv a many-to- 
many relationship 79 te -with Item 80._This global data model is followed in all databases for 
quantified elementary information. 

While the d e scrib e d abov e analysis described above has mainly theoretical 
significance- fa-in practice, it can be used to estimate the Database size. 

In Practically practical application, the following schema should be utilized, see 
according to Figure 10. It is based mostly on the type of query directed towards the database. 
Also, in reality, multiple Nouns in quantified elementary information databases are analyzed 
in same Verbs » so Verbs ar e b e comin g become independent of Nouns. Noun 81 is in many to 
fflan ymany-to-many relationship 83 to Item 85. Verb 82 is in many to manymanv-to-manv 
relationship 84 to Item 85. 

The Database is made of Nouns, Verbs and Items. What is critical in this diagram , 
are the relationships between the basic elements of the sentence. Names given to the basic 
elements of the sentence are here only for clarity of definition. The essence of this design are 
isthe relationships between the parts of the analysis, not the specific names for them. 

Based on the aforementioned, in Figure 10,_a schema using anetwork model 
notation aH -and systems based thereon will be bw tebuilt . In reality all the elements of the 
diagram can be com e d e v e lop e d into finer analysis of th e m. refined into finer detail to 
accommodate higher speed e£retrieval within databases and to simplify the navigation in 
specific databases for a specific area of knowledge being analyzed. 
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To accomplish conversion from network model to relational model of databases, 
two relations are bemg-defined: 

1 . Relation Rl : N Rl V -- in Noun N exists Verb V 

2. Relation R2: V R2 I in Verb V exists Item I 

These two relations must coexist en-for the same set of Verbs, which is closed on 
the Product operation. 

To have arproperly build the database, two thesis have to be true: 

1. Each Item in the database has to be assigned to a Verb or combination of Verbs. 

2. Each Verb has to be assigned to a Noun or combination of Nouns. 

Simply speaking, there are no Items with nonexistent Verbs and/or Nouns._The 
reverse functions also cooperate. 

Basic Cross-Referencing Algorithms of the Database 

The b Basic algorithms of the Database traverse the fully developed Noun and/or 
Verb branches to access the Items. Items by themselves can be accessed in a regular sort 
(index) sequence. To utilize the power of the Database* the retrieval queries have to limit the 
number of retrieved Items based on the query parameters. 

The-A_sample of the Noun Branch is depicted in Figure 1 1 . The basic query reads 
a Noun 86 as the specified View, takes it as the head of the Structure list 87 and scans all the 
elements belonging to the list using the Structure record usmg -and t he connecting sets 86". 
The elements of the View list create the headings 92 of the result spreadsheet in Figure 12. 
Then, for a specified Name 94 with Context 94" treated as the head of another list* it reads all 
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the elements belonging to the Name list using the Structure record 87 and the connecting sets 
86". Then, the connecting sets 86' and 89' and Noun-Item Relationship Record 88 is used to 
find out all Items 89 (93) belonging to the Name list elements*-. aH-AU the Nouns 86 for these 
Items are read and if any of the these Nouns appear on the list which h e ad i as specified in the 
heading 92, than -then such Noun 86 (91) is printed in the intersection of the Item 89 (93) and 
the heading 92. The S ame -same algorithm may be used to traverse the Verb Branch. 

If the Database schema is developed as in Figure 8, then the basic algorithm can 
be extended to utilize the classifications of Nouns (Verbs), which are the records 45, 46 (63, 
64) above the main Noun (Verb) records 49 (65). 

The screen printout in Figure 12 Illustration illustratese f results of the queries4s 
the scr e en printout in Figur e 12 . The expected result of the query is a logical intersection of 
View 90 with Name 94. Each returned Item 93 has to belongs to sets: one is the View set 90 
or its sub-name 92 and another is the Name set 94 or its sub-name 94'. This way A ccordingly, 
the-auser is presented only with Items 93 that fulfill this two dimensional query parameters. 

Self Learning Algorithms of the Database 

Furth e r r Referring to Figure 1 1, the lists 86", 86', 89' mentioned in th e pr e vious 
seetienabove for the Basic Cross-Referencing Algorithms of the Database are ordered by key 
value in records Structure 87 and Noun-Item Relationship Record 88. Same -This a pplies to 
all Structure and Relationship Records in all Figures. .Every time the specific link between the 
lists is utilized, the key value is incremented by a discrete count. This count can be also 
inputted by auser on request. This organizes the list and strengthens the connection between 
the list head and its element. The next time the same list gete-isread, the higher count, i^ 
stronger elements^ are read first. This constitutes the-a_self-learning process of the Database. 
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A Basie -basic structure of Noun (also Verb) record is presented in the Figure 13. It 
contains Context Code 95 and Noun (Verb) Name Value 96. For example, Context Code 0 
(zero) for Global Context and Name with value 'New York'. 

Figure 14 shows the-minimal content of the Relationship (or Structure) record 
containing a_usage count or certainty factor 97._The Noun (Verb) data is a Product of any 
number of multiple other Nouns (Verbs) and their Relationship usage counts 100, tike-as in 
Figure 15. Nouns (Verbs) each carry aContext Code 101 and Noun (Verb) Name Value 102. 

An Exampl e example g iven in Figure 16 contains Noun data, which is built from four other 
products of Noun Name Values 105 and their Contexts 104t-^and their relationship count 103. 

Name and Context Combo and Spreadsheet Interface to the Database 

Referring to Figure 18, visual representation of the Database content is provided. 
Each Name in the Database is stored not only as a value of its content, but also in conjunction 
with its Context. To let a user view and edit the content of such pair of objects, the Name and 
Context Combo is developed. In the preferred embodiment, th e only e xisting implementation 
of th e inv e ntion sucht he Combo is represented by means of two closely visually related list 
boxes: List Box Name 106 and List Box Context 107. In other screens of the preferred 
embodiment Name and Context Combo can be shown as Name and Context columns of a 
screen. Other visualizations are-may display the same content in a different layout. 

Referring to Figure 18, visual representation of the Database content is also 
provided for multiple hierarchical and other relationships between Categories and Items. Each 
Name from the Database may have a list of sub-Names 108 (displayed here with the folder 
picture). .These sub-Names may again be related to their sub-Names. Each Name or sub- 
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Name may have Items 109 (displayed here with the page picture) related to them and 
displayed in proximity of such Name or sub-Name. The list of columns 1 10 is the list of 
Names te-for which a user wants to view relationships to Items. Such list of columns is named 
as View and such Name 1 1 1 is displayed in the View List Box 111. The Name(s) 1 12 
displayed in the cell related to a row and column are the Name(s) relating the name(s) in the 
column heading 1 10 to a Name(s) or Item(s) in the related row 109 or 108. 

For e xampl e B v way of illustration, referring to Figure 18, Name "jackie" from 
Context "global" has Items "call alex soon", "see jackie", another "see jackie" and "call alex 
mondaa mondav ". Name "jackie" from Context "global" has also sub-Name "people". View 
"manager" has sub-Names (and columns) "contact", "people", "completed workl", "assigned 
date" and "alarm". Item "call alex soon" is related to column "people" through Name "alex", 
which is displayed in the intersection of the row for the Item and column for Name "people". 
Item "see jackie" is related to column "people" through Name "jackie", which is displayed in 
the intersection of the row for the Item and column for Name "people". Another Item "see 
jackie" is related to column "people" through Name "jackie", which is displayed in the 
intersection of the row for the Item and column for Name "people". Item "call alex 
mondaa mondav " is related to column "alarm" through Name "call alex monda a mondav ", 
which is displayed in the intersection of the row for the Item and column for Name "alarm". 

Bri e f D e scription of th e Drawings 

Figure 1. illustrates Category Structur e d e p e nd e nci e s for Cont e xt and Nam e s. 

Figur e 2. shows Standard Category Structur e for th e Vi e w Cont e xt. 

Figur e 3. shows Structur e of th e Databas e Information Mod e l. 
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Figure 4. is th e diagram of th e Simplifi e d Structur e of th e Databas e Information Mod e l. 

Figur e 5. shows structur e of a sampl e cat e gory classification. 

Figur e 6. shows all Elem e nts of th e Simplifi e d Database Information Mod e l. 

Figur e 7. shows all El e m e nts of th e Databas e . 

Figur e 8. displays r e alistic schema of th e Databas e for R e ality. 

Figur e 9. is a diagrammatical r e pres e ntation of quantifi e d e l e m e ntary information. 

Figur e 10. is a diagrammatical r e pr e s e ntation of all e l e m e nts of th e quantifi e d e l e m e ntary 
information. 

Figure 11. contains illustration for th e basic r e tri e val algorithm. 

Figur e 12. displays two dim e nsional qu e ry r e sults of the basic r e tri e val algorithm. 

Figur e 13. shows basic structur e of Noun (V e rb) r e cord. 

Figur e 14. shows basic structur e of R e lationship (or Structur e ) r e cord containing usag e count 
or c e rtainty factor. 

Figur e 15. displays product of Nouns (V e rbs) and Structur e of Nouns (V e rbs); with thr ee 
elem e nts. 

Figur e 16. shows e xampl e of product of Nouns (V e rbs) and Structur e of Nouns (V e rbs); with 
four e l e m e nts. 

Figur e 17. contains th e RAIMA® Databas e Data D e finition Languag e Sch e ma for 
BrainAgenda©. 
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Figur e 18. displays two dim e nsional qu e ry results of th e basic retri e val algorithm and shows 
spr e adsh e et int e rfac e . Th e Nam e and Cont e xt Combo is di s played. 



Summary Including Objects and Advantag e s 



This invention is a specific softwar e and/or hardwar e Databas e (Databas e ) d e sign and 
algorithms to acc e ss information in this Databas e . Th e Databas e is a mod e l of th e r e ality. Th e 
most pr e valent charact e ristic of th e Databas e i s it s s e lf organizing of information contain e d in 
th e Database. Th e Databas e cont e nt is dynamic and e ff e ctiv e ly changing th e Databas e its e lf. 
Humans always us e words and phras e s to d e scrib e th e r e ality. Th e s e nt e nces ar e build 
primarily with nouns and v e rbs. Th e m e aning of what is said d e p e nds on th e cont e xt in which 
words ar e us e d, th e n it is conc e ntrat e d on a particular vi e w of th e things and finally the things 
hav e their nam e s. Databas e us es th e s e words to classify th e information. It is intuitiv e , but if 
som e body prefers to us e a diff e r e nt naming conv e ntion, th e Databas e can b e adjust e d by 
customizing it. Th e Databas e includ e s automatic cross r e f e rencing algorithms to r e lat e 
categories and it e ms of information. Main d e sign vi e ws of th e Databas e ar e pr e s e nt e d h e r e — 
oth e rs, not present e d h e r e variations of main d e sign ar e cov e r e d also by this inv e ntion. Th e 
look and f ee l of th e comput e r programs which d e al with us e r fri e ndly pr e s e ntation of th e 
Databas e information and particularly Nam e and Cont e xt Combo ar e describ e d. A comput e r 
syst e m with m e ans of impl e m e nting th e inv e ntion is also d e scrib e d. 

Pr e f e rr e d Embodim e nt — D e tail e d D e scription 
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The-A_preferred embodiment is to b e don e implemented using a Microsoft 
Windows® compatible computer. On such computer a-Network Model Database Manager 
software has to b eis installed. A Database database definition for athe- Network Model 
Database Manager is stored in the-aData Definition Language format file. Th e onlvA n 
existing embodiment of the inv e ntion is in BrainAg e nda BrainAgenda™ Q Personal 
Information Manager software <http://www.brainagenda.com/> . The Data Definition 
Language format file is created using RAIMA® Network Model Database Manager. Figure 
17 shows the Data Definition Language format file specific to and working with RAIMA® 
Network Model Database Manager. The Data Definition Language format file stores the 
database definition, which directly relates to some claims of the invention. This file is called a 
Schema of the Database-: 

Computer Database Manager Listing for the Database Design is represented in Figure 

17. This is a Network Model Database design using a sp e cific RAIMA® Database Manager. 
The Database Design may be directly implemented in a specific computer by supplying the 
Listing to the RAIMA® Database Manager. This schema is the implementation of arealistic 
schema of the Database for Reality as shown in Figure 8. Additional elements included in the 
schema and not represented in the Figure 8 are utilized mostly for performance improvement. 

In Figure 17 all lines and each string starting with two characters / (forward slash) and 

* (asterisk) and ending with * (asterisk) and / (forward slash) are the comment lines or strings. 
Comment string contains text which helps a database analyst understand database features. 
Comment text is irrelevant to the database manager interpretation of the database definition. 

In this d e scription th e rR eferences are dene -made herein by the name of the 
element as it is used in the Figure 17. The database BRAIN is defined with the-apage size of 
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6144 bytes of storage. The file F 1000 10.00 contains records of type noun. The file 
F10001 1.00 contains records of type datar and datar_tabl. The file F100012.00 contains 
records of type noun_datar, noun_str, noun_synonim, datar_str, action_before and 
action after. The file F 1000 19.00 contains records of type brain and note. The key file 
F100010.00K contains keys of type noun.id. The key file F 10001 LOOK contains keys of type 
datar.id. The key file F100019.00K contains keys of type note.id. 

Field types are defined as per languag e C programming language conventions as 
char (character) with length in brackets, long (numerical) and double (numerical, with double 
size). The struct keyword is used to designate the structure name, which includes multiple 
fields. The structure name may be used in ^programming language (for example, C) to 
manipulate the whole named group of fields instead of single fields. The structure name does 
not change the way the included fields behave. 

Definition for record type brain contains multiple fields db_path, db_name, 
typev, kname_v, subtype_v s name_v, type_n, kname_n, subtype n, type2_n, kname2_n, 
subtype2_n, name_n, read_action, next_l, next_2, next_3, value_l, value_2, value_3, 
double_l, double_2, double_3, reserve_l, reserve_2, free, which are not specifically related to 
the invention. These fields are defined for ease of programming to store some additional 
information related to the database as a whole. 

The D efinition definition for record type brain contains also also contains contains 
groups of fields id_v and id_n. 

The D e finition definition for record type noun contains multiple fields type, 
kname, subtype, type2, kname2, subtype2, name, type_p, kname_p, subtype_p, cf, delete, 
joint id, read_action, date_create, date_when, date_done, date_start, date_end, short_name, 
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cat_type, exclusive, settings, layout_link, type_link, knamejink, subtype__link, type_note, 
knamenote, subtype_note, position_note, free_l, free_2, reserve_l, reserve_2, reserve_3. 

Definition for record type noun also contains also also contains groups of fields id, 
id_p, id_link and id_note. Group of fields id relates to basic structure of Noun (Verb) as 
shown in Figure 13. CONTEXT Code 95 relates to field type, NOUN Name Value 96 relates 
to field kname. Field kname contains first 40 bytes of the full NOUN Name Value 96. Field 
name contains all 255 bytes of the NOUN Name Value 96. In the-a Pr e f e rr e d preferred 
Embodim e nt embodiment i s implem e nted a product of Nouns (Verbs) and Structure of Nouns 
(Verbs) is implemented with two elements as related to Figure 15. As related to Figure 15, 
CONTEXT Code 1101 relates to field type, NOUN Name Value 1 102 relates to field kname. 
Field kname contains first 40 bytes of the full NOUN Name Value 1 102. CONTEXT Code 2 
101 relates to field type2, NOUN Name Value 2 102 relates to field kname2. Field kname2 
contains first 40 bytes of the full NOUN Name Value 2 102. A D e finition definition for record 
type noun relates directly to Noun 49. 

A D e finition definition for record type datar contains multiple fields type, kname, 
subtype, name, cf, delete, joint_id, read_action, date_create, date_when, date_done, date_start, 
dateend, settings, type_note, kname note, subtype_note, position_note, long_l, reserve_l, 
reserve_2, reserve d, reserve_4. 

A_Ddefinition for record type noun contains also also contains groups of fields id 
and id_note. Field kname contains first 40 bytes of the full Item 55. Field name contains all 
255 bytes of the Item 55. Definition for record type datar relates directly to Item 55, 

A D e finition definition for record type datar_tabl contains multiple fields elem, cf, 
delete, date_create, read_action, double_l, reserve_l, reserve_2. 
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A Definition definition for record type note contains multiple fields from, type, 
kname, subtype, pagejir, name, cf, chapter, chapter_l, chapter_2, chapter_3, chapter_4, 
chapter_5, chapter_6, verse, page, delete, read_action, reserve_l, reserve_2, reserve_3, 
reserve_4. 

A Definition definition for record type note contains also also contains group of 
fields id. Field kname contains the first 40 bytes of the full page. Field page contains all 5000 
characters of a page of text stored in the database. . The D e finition definition for record type 
note relates directly to Note 61 . 

A Definition definition for record types noun_str, noun_datar, datar_str contains 
multiple fields cf, date_create, read_action, double_l, reserve_2, reserve_3. Field cf relates to 
basic structure of Relationship (or Structure) record containing usage count or certainty factor 
as shown in Figure 14 Count 97. In the Preferred Embodiment is impl e m e nt e d a_product of 
Nouns (Verbs) and Structure of Nouns (Verbs) is implemented w ith elements as related to 
Figure 15. As related to Figure 15, Count 1 or Count 2 or Count 3 100 relates to field cf. The 
D e finition definition for record types noun_str, noun_datar, datar_str relates directly to 
Structure records 48, 53, 75. 

A D e finition definition for record types action_before, action after, 
noun_synonim contains multiple fields cf, date_create, read_action, double_l, reserve_2, 
reserve_3. 

All sets in the schema are ordered descending by the cf fields from the member 

records. 
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ADdefinition for set noun_set contains record brain as the owner and record noun 
as the member. 

A D e finition definition for set datar_set contains record noun as the owner and 
record noun_datar as the member. 

A D e finition definition for set datar_noun_set contains record datar as the owner 
and record noun_datar as the member. 

A D e finition definition for set noun_synonim_exp_set contains record noun as the 
owner and record noun_synonim as the member. 

A D e finition definition for set noun_synonim_imp_set contains record noun as the 
owner and record noun_synonim as the member. 

A D e finition definition for set noun_exp_set contains record noun as the owner 
and record noun_str as the member. 

D e finition A definition for set noun_imp_set contains record noun as the owner 
and record noun_str as the member. 

A D e finition definition for set datar_exp_set contains record datar as the owner 
and record datar_str as the member. 

A D e finition definition for set datar_imp_set contains record datar as the owner 
and record datar_str as the member. 

A D e finition definition for set action_before_exp_set contains record noun as the 
owner and record action before as the member. 
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A D e finition definition for set action_before_imp_set contains record noun as the 
owner and record action_before as the member. 

A D e finition definition for set action_after_exp_set contains record noun as the 
owner and record action_after as the member. 

A D e finition definition for set action_after_jmp_set contains record noun as the 
owner and record action_after as the member. 

A D e finition definition for set datar_tabl_set contains record datar as the owner 
and record datarjabl as the member. 

Whil e th e inv e ntion has b ee n d e scrib e d in connection with a pref e rred e mbodim e nt, it 
is not int e nd e d to limit th e scop e of th e inv e ntion to th e particular form s e t forth, but on th e 
contrary, it is int e nded to cov e r such alt e rnativ e s, modifications, and e quival e nts as may b e 
includ e d within th e spirit and scop e of th e inv e ntion as d e fined by th e append e d claims. 

Pr e f e rr e d Embodiment — Operation 

Algorithms of the-Da database asdescribed in this inv e ntion herein are implemented in 

BrainAgenda™- ©, available at <http://www.brainagenda.com/> . Specific source code of 
programs which perform the algorithms is written for the current usage of the Databas e 
database in the Personal Information Manager operation. 

The basic algorithms of the Database traverse the fully developed Noun and/or 
Verb branches to access the Items. Items themselves can be accessed only in a regular sort 
(index) sequence. To utilize the power of the Database A the-retrieval queries have to limit the 
number of retrieved Items based on the query parameters. Geed -Figure 12 illustration 
illustratese f results of &e-a_queriesy is th e scre e n print in Figur e 12 . The expected result of the 
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query is a logical intersection of View (and Context) with Names (and their Contexts). Each 
returned Item has4e-belongs to two sets: one is the View set and another is the Name set. This 
Thus w a^-the user is presented only with Items that fulfill said two dimensional query 
parameters. 

Referring to Figures 8, 12 and 18, the basic query reads a Noun Record (49, noun) 
as the specified View (1 1 1), takes it as the head of the list and scans all the elements 
belonging to the list using the STRUCTURE (48, noun_str) record. The elements of the View 
list create the headings (1 10) of the result spreadsheet. Then, for the specified Name (and 
Context) reads a Noun Record (49, noun) treated as the head of another list it reads all the 
elements (108) belonging to the Name list using the STRUCTURE (48, noun_str) record. 
Then, for all the Items (55, datar, 109) belonging to the Name list elements all the Nouns (49, 
noun, 1 12) are read and if any of the these Nouns appear on the list which head is specified in 
the heading (110), than -then such Noun is printed in the intersection (1 12) of the Item and the 
heading. 

The S ame -same algorithm as described above may be used to traverse the Verb 
branch. The basic algorithm can be extended to utilize the classifications of Nouns (Verbs) — 
the records above the main Noun (Verb) records. 

Other Embodiments 

Intelligent Device — Description 

Any intelligent Device has to have aKnowledge Bank. This -The Knowledge Bank 

may be implemented in the-acomputer by utilizing a_database as d e scrib e d in this according to 
the invention. 
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Intelligent Device — Operation 

As discussed above, A w-an intelligent Device has to have Knowledge Bank. This 
The K nowledge Bank may be implemented in the-acomputer by utilizing database operation 
algorithms as described in this invention. 

Conclusions, Ramifications, and Scop e 

Accordingly, it can be seen that this-adatabase design according to the invention 
allows a system, which uses the invention, to perform highly effective storage of any number 
of pieces of information and their relationships to other pieces of information. As such the 
invention may be, and is, utilized for storage of dissimilar pieces of information in practical 
implementations especially useful for Information Managers and Knowledge Banks. 

Although the description of the invention embodiment contains many specificities, 
these should not be construed as limiting the scope of the invention but as merely providing 
illustrations of some of the presently preferred embodiments of this invention. Various other 
embodiments and ramifications are possible within invention's scope. For example, this 
database design allows a system, which uses the invention to perform highly effective storage 
of any language sentences (languages different than English). Above that, it also performs 
functions similar to human brain, namely, it stores unlimited number of connections between 
pieces of information, automatically cross-references them and self-organizes them according 
to any learning pattern, for example, frequency of usage of a piece of information in 
relationship to other pieces of information. 

While the invention has been described in connection with a preferred embodiment, it 
is not intended to limit the scope of the invention to the particular form set forth, but on the 
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contrary, it is intended to cover such alternatives, modifications, and equivalents as may be 
included within the spirit and scope of the invention as defined by the appended claims. 

Any computer system with means of implementing the invention is considered to 
contain the invention. 

The scope of the invention should be determined by the appended claims and their 
legal equivalents, rather than by the examples given. 



Page 32 of 33 



Self-Organizing and Automatically Cross-Referencing Information Management System 

Abstracts 

This invention is a sp e cificA software and/or hardware ©database system and 
method-(Database) having a design and algorithms to access information in this-the Databaser 
The Database is utilizes a model of the reality. Th e most pr e val e nt charact e ristic of tT he 
Database is fts-self-organizing of information contained in th e Databas e. The Database content 
is dynamic and effectively changing changes t he Database itself. Humans always us e words 
and phrases to describe the reality. Th e s e nt e nc e s ar e build primarily with nouns and v e rbs. 
The m e aning of what is said d e p e nds on th e cont e xt in which words are us e d, then it is 
concentrated on a particular vi e w of th e thing s and finally th e things hav e th e ir nam e s. T he 
Database uses concepts of nouns, verbs and context t hes e words t o classify4he information, ft 
is intuitive, but if somebody pr e fers to us e a diff e r e nt naming conv e ntion, th e Database can be 
adjusted by customizing it. T he Database includes automatic cross-referencing algorithms to 
relate categories and items of information. Main d e sign vi e ws of th e Databas e ar e pr e s e nt e d 
here — others, not pres e nt e d h e re variations of main design are cover e d also by this inv e ntion. 
Th e look and f ee l of th e comput e r programs which d e al with us e r fri e ndly spr e adsheet 
pres e ntation of th e Database information and particularly Nam e and Cont e xt combo are 
described. Any comput e r system with m e ans of impl e m e nting the invention i s also d e scrib e d. 
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